Document Revision No: [12] Date of Creation: [[03-SEP-2019]]
Date of Last Revision: [[14-MAR-2025]]
Document File Name: [J9_OTA_NVTR_DIGITAL_API_INTEGRATION_KIT_V2.1.DOCX]
Integration Specifications
For ‘Navitaire Digital API’ Version 2.1
Hold Booking 14
Fare rules information 14
Other Information 15
Mange Booking Flow 70
Name | Revision Date | Reason For Changes | Version |
Fare Bundles | 08-JAN-2020 | Launch of new fare bundles(Economy Light, Value & Extra) | 1.1 |
Travel Extras | 08-MAR-2020 | Access allowed for SSRs (Meals, Extra baggage etc.) | 1.2 |
All-inclusive Fare | 01-AUG-2020 | All-inclusive price details in flight availability response | 1.3 |
Retrieve booking, Seat assignment changes | 10-NOV-2020 | New endpoints for retrieve booking using PNR, Get passengers & seat assignment changes. | 1.4 |
Further API clarifications | 12-OCT-2021 | Clarifying more about APIs including handling infants, passenger document, booking a seat and more about SSRs | 1.5 |
Enrich practical API integration steps | 01-JAN-2022 | Support APIs with more explanation and some screenshots to make integration process easier and faster. Distinguish between required and optional APIs. Plus, explaining seat availability and assign APIs. | 1.6 |
Session creation clarification | 23-FEB-2022 | Explain session creation best practice to avoid opening too much un-required abandoned sessions. | 1.7 |
BSP Payment Option | 28-Nov-2022 | New payment option- BSP | 1.8 |
Hold Booking | 30-JUL-2023 | Hold booking functionality – Only for AG Payments | 1.9 |
Credit Card Payment Option | 25-JUL-2024 | New payment option- Credit Card (CC) | 2.0 |
Manage Booking Flow | 25-JUL-2024 | Modification/Cancellation feature for the booking which was already created. | 2.0 |
4.7 upgrade | 14-MAR-2025 | Response Changes as part of Navitaire Digital API 4.7 Upgrade | 2.1 |
Service Bundles | 14-MAR-2025 | New feature for adding Service Bundles | 2.1 |
Navitaire Digital API integration guide
Use of Navitaire Digital API to
Check flight availability
Create new booking
Add SSR
Check seats availability and select seat during or after booking
Add passenger’s documents
Get fare rules
Get account balance and make payments
Swagger (https://rtestupgrade.jazeeraairways.com/swagger)
Postman (Using the OTA integration with postman file. This file will be attached among this documentation file and test cases).
Developers Business Managers UAT testers
Use of Navitaire Digital APIs for booking of Jazeera tickets
Navitaire documentation Navitaire knowledge base Navitaire support tool
Since New Skies requires a session for all API interactions, proper session management is paramount to performance. Applications should re-use sessions for repetitive functions of a single booking and explicitly call Logout at the end of processes to dispose of the session and free app server memory.
New Skies requires that all consumers of the API logon to validate credentials, verify access level, and to instantiate the session that will be used throughout the subsequent interactions. The Logon method may seem lightweight, but in reality a series of lookups is happening in the background. This makes the Logon call one of the heavier calls from a processing standpoint. With this information in mind, it is best to make wise use of Logon by not needlessly logging on over and over for repetitive functions.
The explicit use of Logout is also recommended to prevent unexpired (abandoned) sessions from building up and causing application degradation. To logout, use Token API with DELETE method. Refer to section 5.8.2 – point 16 for further details.
Note: Repetitive calls to login API and excessive abandoned sessions can result in resource constraints and performance degradation.
Each successful login (Token API call) is associated with one session. Within this one session, Availability API and BookingQuote API can be called multiple times, one call to TripSell API, add SSRs, pay the booking fully and confirm (commit) the booking to obtain the PNR. Then, Logout needs to be called to close the session.
So, Token API should be called only in the following cases:
Token expiration after idle time (15 minutes). Refer to section 2.3.
After a booking cycle is finalized. That is, CommitBooking API is called and a corresponding recordLocater (PNR) is obtained with dueBalance = 0 (confirmed booking).
If proceeding with a booking is not required after availability searches, logout API should be called.
Over requesting: Unnecessary repetitive calls to login API specially and other APIs generally exhausts the server and slows response time. Hence, User ID would be blocked temporarily as a result if number of calls exceeds 200 calls per minute. The API integration should make wise use of login (Token) API and credible number of hits to other APIs.
The use of session pooling can reduce the number of individual sessions in memory. An effective session pool limits the number of sessions that can be used concurrently and employs a check- in/checkout system with the sessions. As sessions are freed up they can be checked-in and checked-out by other threads so as to limit the memory footprint on the app server. When all processing is done the sessions should be logged out, releasing them from memory.
Search requests are stateless calls and do not need to be tied to a specific session. One call after another can be made on the same session without the need to call Clear or Logout. Reuse of sessions in this case can reduce stress on the system and prevent unnecessary session usage.
The current session timeout is 15 minutes. That is, the idle time between each two consecutive API calls. It’s showing in after generating the token.
"idleTimeoutInMinutes": 15
Check credit balance
GetAvailability
Three new Product Class codes have been created for Economy Class Cabin:
Economy Cabin Product Class Codes,
EL (Economy Light)
EV (Economy Value)
EE (Economy Extra)
Business Cabin Product Class Codes,
BU (Business) (Currently, it is only available for [KWI-CAI] and [CAI-KWI] flights)
Sell segment/s Add payment
AG Payment Option
CC (Credit card) Payment Option
BSP Payment Option
BSP Cash
BSP Easy Pay
Note: The Agent ID should be under IATA Organization ID to avail BSP Payment option.
For testing BSP Payment in staging environment kindly note that the agency IATA ID should be registered under the IFG Test Environment.
In case of no Test IATA ID available, please use the production credentials to make a test booking (using PAX name as test tester) and share the PNR for refund.
Add comments Commit changes
GetFareRules information
Online retail travel agents
These travel agents sell multiple airline fares through their unique portal. Their target customers are:
Direct customers
Travel agents
These are standard APIs that’s been used by a number of Navitaire airlines.
Support below TLS 1.2 is discontinued
The IP address that is used to access the API must be whitelisted by Navitaire
Navitaire Digital API documentation FAQ
Sample API test cases: a set of APIs that shows how API requests and responses are to make a booking for a different cases. It can be found attached to the OTA registration email.
OTA Integration Postman Collection (A fast way to import APIs to a Postman Collection). It also can be found attached to the OTA registration email.
This document is prepared with tests done using Swagger or Postman Navitaire API can be consumed using .NET, JAVA and other development tools
The current API version is 4.7.3
Title | Description |
MISS | Miss |
MR | Mr |
MRS | Mrs |
MS | Ms |
MSTR | Master |
CHD | Child |
The Logon API is used to generate token (or session ID or signature). You will need username (agent ID or UserID) and password to generate the token. The domain code is “WW2” and the Channel type is “API”
Password must be at least 6 characters, no more than 8 characters, only contain letters or numbers. The password cannot contain symbols.
In case the account is locked or password expired or any other query related to your production credentials, please contact apisupport@jazeeraairways.com for further help
IPs must be whitelisted by Navitaire for access. Contact apisupport@jazeearaairways.com for this purpose.
Economy Cabin Product Classes
Business Cabin Product Class (Currently, it is only available for [KWI-CAI] and [CAI-KWI] flights)
Turnaround Time for IP whitelisting is 7 business days.
ECONOMY | |||
Fare Brand (Product Class) | Economy LIGHT – EL | Economy VALUE – EV | Economy EXTRA - EE |
Cabin Baggage | ADT,CHD - 7 KG/1 PIECE INFT - 10KG | ADT,CHD - 7 KG/1 PIECE INFT - 10KG | ADT,CHD - 7 KG/1 PIECE INFT - 10KG |
Checked Baggage** | NO BAGGAGE (* As per the weight received from system.) | 20KG/1 PIECE (* As per the weight received from system.) | 30KG/2 PIECES (* As per the weight received from system.) |
Purchase Baggage | Only available at Check-in | Pre-purchase 10KG online | Pre-purchase 10KG online |
Change | Pay to Change | Pay to Change | Pay to Change |
Cancellation | Non refundable | Pay to cancel up to 24 hours prior to departure | Pay to cancel up to 24 hours prior to departure |
BUSINESS | |
Fare Brand (Product Class) | Business – BU |
Cabin Baggage | ADT,CHD - Total Weight 15 KG (2 PIECES) INFT - 10KG |
Checked Baggage** | 60 KG/3 PIECES (* As per the weight received from system.) |
Purchase Baggage | Only available at Check-in |
Change | Pay to Change up to 3 hours of departure |
Cancellation | Pay to Cancel up to 3 hours of departure |
For more information about different classes and rules, refer to the following link: https://www.jazeeraairways.com/en-kw/plan/flight-information/fare-options
** Checked Baggage Allowance:
Weight - should be displayed as per data received dynamically from the system. Use booking quote endpoint to get the baggage allowance from the system.
We have two types of Aircraft:
A320 CEO
A320 NEO
SSRs are inventory controlled. SSRs will vary according to route and cabin/fare classes. Other restrictions may include seat and availability restrictions.
It is important to read the SSRAvailability response to check if the SSR is available for the selected flight. Extra baggage can be booked 4 hours prior departure.
Meal can be booked before 24 hours prior departure.
SSR pricing is dynamic. It may depend on the sector, travel date, TA ID or service bundles selected. For the connecting sectors, pass SSR separately for each leg.
For extra baggage use ssrType BaggageAllowance; extra baggage SSR limited to 1 per PAX per sector.
Extra baggage not available for Economy Light (EL)
For the connection sector booking, Extra baggage (XB10) should be added for both the segments. For meals use ssrType Meal.
LOUN available only for flights departing from Kuwait. LOUN can be assigned for both the Adult (ADT) passenger and child (CHD) passenger. LOUN is limited to 1 per passenger.
PRRT is limited to 1 per passenger.
Meals
Pearl Lounge Service
SSR Code | Name |
LOUN | Pearl Lounge Service at KWI T5 |
PRIORITY Check-in
SSR Code | Name |
PRRT | PRIORITY Check-in, Boarding and Baggage |
Extra baggage
SSR Code | Name |
XB10 | Extra Baggage 10 KG |
For more details refer the following links: https://www.jazeeraairways.com/en-kw/plan/book/jazeera-cafe
https://www.jazeeraairways.com/en-kw/experience/at-the-airport/jazeera-lounge
https://www.jazeeraairways.com/en-kw/plan/book/priority-service
Infants are considered SSRs. To check possibility of adding them and the related fair, use
BookingQuote API and set the value of “infantsCount”.
Add infants to reservations by setting the value of “infantsCount” in TripSell API.
After adding infants to a reservation, related data need to be added in Passenger request API as shown below:
Seats can be optionally reserved as a part of the reservation process. After booking a flight using TripSell API, check availability of seats using SeatsAvailabilityBySegment API. Pass segmentKey (the one used in booking the flight). Make sure to check the “availability” node value (an integer represents seat availability and must have value of 5). Also, get the unitKey of the desired seat.
Availability of seats may have the following values [0-'Unknown', 1-'Reserved', 2-'Blocked', 3- 'HeldForAnotherSession', 4-'HeldForThisSession', 5-'Open', 6-'Missing', 7-'CheckedIn', 8- 'FleetBlocked', 9-'Restricted', 10-'Broken', 11-'ReservedForPnr', 12-'SoftBlocked', 13-'Unavailable']. Booking a seat will not succeed if seats availability value is not 5.
Add the seat to the booking using seatAssignment API. Use the “unitKey” acquired form seat availability API.
URLs: https://rtestupgrade.jazeeraairways.com/swagger
OTA Login credentials will be shared once finalized the agreement
Please refer to this documentation and to OTA Navitaire Digital API integration FAQ document as an immediate reference point. For IP Whitelisting and technical queries that are not mentioned inprevious references, contact apisupport@jazeeraairways.com. The usual response time for all non-production emergency services is up to 3 business days.
For NDA signing, OTA registration and Credential related queries, contact apiregister@jazeeraairways.com . The usual response time for all non-production emergency services is up to 3 business days.
A production emergency occurs when an integration that was working on production, doesn’t work leading to 100% booking failures.
The booking methods retrieve data, modify booking state, or add a booking in the database. The session created when a user logs on contains a booking state that is used through creating, modifying getting the booking.
Methods such as AddPaymentToBooking and CommitBooking modify the booking state. The methods that update the booking state usually return responses that indicate success or failure of the method and may contain data needed in subsequent steps. Methods such as BookingDetails, AvailableSSRs and Availability retrieve data. The BookingCommit method is used to finalize a booking by combining the data contained in a booking commit request with the booking data in booking state and if there are no errors writes it to the database.)
Sample Tasks:
Create new bookings
Find bookings by multiple criteria
Get inventory availability and pricing
Get SSR availability and pricing
The basic API call sequence required to make a booking (using AG Account) is as the following:
Acquire a token (login)
Check flight availability
Sell a trip
Add passenger and contact information
Add payment to booking
Commit booking (to obtain PNR or recordLocator)
Get booking status (to check the booking status whether it is confirmed/hold/failed)
Logout
The basic API call sequence required to make a booking (using BSP Payment) is as the following:
Acquire a token (login)
Check flight availability
Sell a trip
Add passenger and contact information
Commit booking (to obtain PNR or recordLocator)
Get booking status (to check the booking status whether it is confirmed/hold/failed)
Make BSP Payment
BSP Cash
BSP Easy Pay
Get booking status (to check the booking status whether it is confirmed/hold/failed)
Logout
The basic API call sequence required to make a booking (using Credit Card (CC) Payment) is as the following:
Acquire a token (login)
Check flight availability
Sell a trip
Add passenger and contact information
Commit booking (to obtain PNR or recordLocator)
Get booking status
Make CC (Credit card) payment
Get booking status (to check the booking status whether it is confirmed/hold/failed)
Logout
The following APIs are optional and can be called optionally as needed:
Booking Quote (for fare breakdown, Infant fare & baggage info)
Get passengers
Add passenger travel document
Get SSRs
Add SSRs
Get seat availability by segment
Assign seat
Check organization account balance (Agency Credit)
Get booking status (to check the booking status whether it is confirmed/hold/failed)
Currency Converter
The basic API call sequence required to make a hold booking (using only AG Account) is as the following:
Acquire a token (login)
Check flight availability
Sell a trip
Add passenger and contact information
Get Available Hold Date
Add Hold Fees (For all passengers)
Add payment (Hold Fee) to the booking (with deposit flag as true)
Commit booking (to obtain PNR or record Locator) by passing the above hold expiration date. Note: Please pass the header confirmHoldBooking as true.
Get booking status (to check the booking status whether it is confirmed/hold/failed)
Logout
The following APIs are required to complete the Hold booking within the hold period time.
Acquire a token (login)
Retrieve the booking using PNR/Record locator
Check the balance due on the booking
Add Payment to booking
Commit booking
Get booking status (to check the booking status whether it is confirmed/hold/failed)
Logout
The following APIs are optional and can be called optionally as needed:
Booking Quote (for fare breakdown, Infant fare & baggage info)
Get passengers
Add passenger travel document
Get SSRs
Add SSRs
Get seat availability by segment
Assign seat
Check organization account balance (Agency Credit)
Get booking status (to check the booking status whether it is confirmed/hold/failed)
Currency Converter
You can retrieve the fare rules based on Farekey (fareAvailabilityKey).
Currency Converter – this method helps to convert currency based on currency code.
Currency Information – this method helps to give the information of all currencies configured in system along with currency code, display digits and description.
The baggage allowance configured based on fare rules
Will get the information using “Booking Quote” method.
Organization Account
Organization Account Transaction
Stations Cities Countries
Sector Based Message Station Local Time
Source Organization Should be your organization code so that booking reflects to your account. Meal & Seat configured based on leg and other SSR’s configured based on journey.
Passenger Details and Passenger Contact are added in the same request.
Fare break up is available in booking quote method. Which is nothing but Price Itinerary Request. It is possible to add multiple pairs of fareAvailabilityKey and journeyKey in the same request.
Always use the culture as “en-GB” in Contact request.
Use the organization ID in your passenger contact request ("sourceOrganization": “Agency Organization ID”) & payment requests ("ACCTNO": "Agency Organization ID ")
For the Jazeera Itinerary add the tag “distribution = ‘Email” in passengercontact method.
Itinerary sending option can be controlled from booking commit request by setting “notifyContacts”- true/false.
Itinerary sending option is disabled in production and the itinerary emails will be triggered only from TEST environment.
Use CompressionType": "CompressByProductClass" in availability request to get the fare bundles (Economy Light, Value & Extra)
One Way, Roundtrip, Connecting Booking – 2 ADT, 2 CHD, 1 INFT
Payment with Agency account (AG) or Card
Product Class - Economy Light (EL), Economy Value (EV) and Economy Extra (EE)
Passenger qty. should be less than or equal to 9
Add SSR like, Meal, Baggage (Extra baggage should be added to both segments of connecting flights)
Booking Flow (For AG Account)
The following information describes the steps used to make a booking. Refer to section 5.1 (New Booking) to check the basic and mandatory steps to make a booking. Remaining APIs are optional and can be used if needed. Also, for each API, check its corresponding test case (in the test cases file attached to OTA registration email) in-order-to see its request body and the corresponding successful response.
Get Token – Creates the general access token that will grant access to the API. Token idle time out is 15 minutes. That is, the token will expire if idle time between each two consecutive API calls is greater than or equal to 15 minutes.
Token API should be used wisely as each successful login is associated with one session. Please refer to section 2.1 for best practices regarding session management and avoiding resource leaking.
Successful Token API request and response looks similar to the following (refer to test cases attached in the organization registration email for full examples including request body and header data (using Postman or Swagger). Agents may require whitelisting server IP address.
Get Availability – Searches for flights with the full availability search request. This request allows for total control over the configuration or criteria. If a property is not set, default values will be set instead. These defaults are what we consider a general optimized request. If these optimizations are not preferred the requester will need to opt out the filters on the availability request.
Note: You'll always receive the fares in availability response in origin station default currency regardless of which currency you pass in the request. All the remaining API call requests (BookingQuote, TripSell, BookingCommit, etc) need to use the currency specified in the availability API response. If you want to display fares for customer in any other currency, use currency conversion API.
Pass AgentID (UserID) in the availability request header to get the availability response.
The default values that will be set unless specified:
TaxesAndFees = TaxesAndFeesRollupMode.None
Criteria.SsrCollectionsMode = AvailabilitySsrCollectionsMode.None
Criteria.Filters.FareInclusionType = AvailabilityType.Default
Criteria.Filters.CompressionType = FareClassControl.LowestFareClass
Criteria.Filters.Loyalty = LoyaltyFilter.MonetaryOnly
Criteria.Filters.FlightType = FlightType.All
Criteria.Filters.ExclusionType = AvailabilityFilter.ExcludeUnavailable
Criteria.Filters.SortOptions =
JourneySortKey.LowestFare, JourneySortKey.EarliestDeparture, JourneySortKey.ShortestTravelTime
Filters.ConnectionType = SoldAsConnectionType.None
Criteria.Filters.MaxConnectingFlights = 0
Criteria.Stations.SearchDestinationMacs = false
Criteria.Stations.SearchOriginMacs = false
Criteria.Filters.BundleControlFilter = BundleControlFilter.Disabled
NumberOfFaresPerJourney = 1
Successful Availability API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Booking Quote (Price Itinerary) - Retrieves fare breakdown, baggage allowance and infant fare based on the request. You will get full value including tax of the each component.
The availability response will only return adult and child fares. When infants are added to a flight search, it is necessary to use the booking quote response to obtain the fares.
Baggage allowance information can also be obtained from the booking quote response.
Pass AgentID in the Booking quote request header to get the response. You can pass one or multiple pairs of journeyKey and fareAvailabilityKey in a single booking quote request. So, round trips, connecting flights or multiple flights can be queried in a single booking quote API request (Ex. for both inbound and outbound flights). Duplicate journeykey is not allowed in a request. Calling this API is optional and not necessarily happens after each availability request unless the information returned by it is required (infants fare, baggage allowance, fare breakdown …etc.).
resulting from URL length issues. Successful BookingQuote API request and response looks
similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
4. Trip Sell - Sells the list of journeys and creates a booking if it doesn't already exist. You can sell
the infant using this method. Roundtrips must include journeyKey and fareAvailabilityKey of both outbound and return flights in the same API call.
Pass AgentID in the Trip Sell request header to get the Trip Sell response. Successful TripSell API request and response looks similar to the following:
Note: Although this endpoint behaves like a GET, POST is used to reduce the limitations
5. Add Passenger and Contact Info (Passengers API) – Update the booking passenger(s) information and contact details based on the passenger key.
Use can use the agency contact information to update the contact details.
Pass AgentID in the Add Passenger and contact request header to get the Add Passenger and contact response. Successful Passengers API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
6. Get Passengers – Get the collection of passenger(s) on the booking along with passengerkey. Successful GetPassengers API request and response looks similar to the following:
7. Seats Availability by segment- checks for available seats for a specific segment of a flight. There need to be a booking in the session (calling TripSell) in order to check seats availability. It takes segmentKey (the journeyKey of the segment you wish to assign seat(s) in it) as a parameter as the following:
Check available seats (if the node value is "5" (Open)). It is important to check the “Availability” node in the seat availability API response before assigning the seat as shown below.
The “availability” key is a single digit and it represents the availability of the seat. It may have
the following values [0-'Unknown', 1-'Reserved', 2-'Blocked', 3-'HeldForAnotherSession', 4- 'HeldForThisSession', 5-'Open', 6-'Missing', 7-'CheckedIn', 8-'FleetBlocked', 9-'Restricted', 10- 'Broken', 11-'ReservedForPnr', 12-'SoftBlocked', 13-'Unavailable']. Booking a seat will not succeed if seats availability value is not 5.
For roundtrip flights or connecting flights, checking seat availability and assigning a seat should happen for each segment of the flight.
Obtain the unitKey of the available seat you wish to assign to use it in seatsAssignment API.
8. Seat Assignment- As the name suggests, it assigns a seat for a passenger. The API takes
segmentKey (the journeyKey of the journey you wish to assign seat(s) in it) as a parameter. The request body must include the unitkey (obtained by calling get seatsAvailabilityBySegment API) and the passengerkey (obtained by calling GetPassengers API). Successful GetPassengers API request and response looks similar to the following:
Get Available SSRs– To get all the available SSRs. Returned SSRs are classified under journey, segment and leg SSRs. It is important to check this API before adding SSRs since some SSRs may not be available on some airports or even within the same flight (Ex. Due to seat restrictions). Also, you will need to acquire the SSRKey of the SSR (in case it is available) form this API in order to use it in SellSSR API as shown below:
Successful AvailableSSRs API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Add SSRs (SellSSR) –To add the required SSRs. For connected flights, an SSR need to be available and added to all segments if passenger requested to have SSR on the full flight. For some SSRs (like extra baggage XB10 or XB20), it is a must to have the SSR on both segments. In the request body, use the SSRKey obtained in get AvailableSSRs API. Successful SellSSR API request and response looks similar to the following:
For the Meals SSRs, ssrKey is available under legSsrs tag as below
Check response from /api/jz/v1/Booking/AvailableSSRs,
For the connecting sectors, for meals pass SSR separately for each leg. To get SSRs available for each leg, take response from /api/jz/v1/Booking/AvailableSSRs, check SSRs available for each leg and pass SSRs accordingly,
SSRs like Extra baggage (XB10), PRRT can get from /api/jz/v1/Booking/AvailableSSRs response under journeySsrs for each passenger ssrKey is available.
In case of connection booking, the SSRs like XB10 and PRRT will be added for the whole journey, so it will be applied for both sectors.
In the below figure for XB10, name (highlighted) in the figure below can be taken to display the SSR name for XB10 SSR.
Passenger Availability can check in the /api/jz/v1/Booking/AvailableSSRs response as below. In the figure below we can see the SSR key for TSML (SSR) for the passenger key MCFBRFQ-
For the LOUN corresponding ssrKey is available under segmentSsrs tag in the
/api/jz/v1/Booking/AvailableSSRs response.
11. Add passenger travel Documents: Use PassengerTravelDocument API to add the passport details. “issuedByCode” is a two letters country code represents passport issued country (Ex. “IN” stands for India) and “number” is represents passport number. Set “documentTypeCode” to “PASS” for passport as shown below or set it to be “I” for CivilID.
Adding travelling document is an optional step and it can be done during check-in process. Successful PassengerTravelDocument API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Check Agency account balance – To make sure the agency account has sufficient account balance to make the payment/booking. The response will contain the below:
Add payment to booking – Update the payment using Agency account (AG) mode. Account number (ACCTNO) should be the Organization ID.
Adding any paid services need to have corresponding payment added. To pay in full, take amount (balance due) from booking details API and pass it in the Add Payment request.
In Swagger,
Pass AgentID in the Add Payment request header and pass your organization ID as a value for ACCTNO. Over or underpayment is not allowed and committing the booking will not succeed is such case. Successful AddPaymentToBooking APIrequest and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Commit Booking - Commits stateful changes made and finalize the booking. In case of overpayments or underpayments, commit booking API will not succeed. The amount paid
should match to the due
Confirmed booking: Always check the “balanceDue” parameter in the commit booking response to make sure the booking is confirmed or not. It will be zero for confirmed bookings.
Itinerary sending option can be controlled from booking commit request by setting “notifyContacts”- true/false.
Itinerary sending option is disabled in production and the itinerary emails will be triggered only from TEST environment.
This feature will be enabled the production environment, upon request from the agency. Pass AgentID in the commit booking request header. Successful AddPaymentToBooking API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples). The PNR (recordLocator) will be included the response of this API)
Get Booking Status-To get the booking and payments status.
Pass BookingDetailsType value as BalanceDue.
For confirmed bookings and in BookingDetails API response:
status should be “Confirmed”.
paidStatus should be ”PaidInFull”.
balanceDue should be zero as shown below:
16. Logout- Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it). API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Booking Flow (For BSP Payment)
The following information describes the steps used to make a booking using BSP Payment. Refer to section 5.1 (New Booking) to check the basic and mandatory steps to make a booking using BSP Payment. Remaining APIs are optional and can be used if needed. Also, for each API, check its corresponding test case (in the test cases file attached to OTA registration email) in-order-to see its request body and the corresponding successful response.
Get Token – Creates the general access token that will grant access to the API. Token idle time out is 15 minutes. That is, the token will expire if idle time between each two consecutive API calls is greater than or equal to 15 minutes.
Token API should be used wisely as each successful login is associated with one session. Please refer to section 2.1 for best practices regarding session management and avoiding resource leaking.
Successful Token API request and response looks similar to the following (refer to test cases attached in the organization registration email for full examples including request body and header data (using Postman or Swagger). Agents may require whitelisting server IP address.
Get Availability – Searches for flights with the full availability search request. This request allows for total control over the configuration or criteria. If a property is not set, default values will be set instead. These defaults are what we consider a general optimized request. If these optimizations are not preferred the requester will need to opt out the filters on the availability request.
Note: You'll always receive the fares in availability response in origin station default currency regardless of which currency you pass in the request. All the remaining API call requests (BookingQuote, TripSell, BookingCommit, etc) need to use the currency specified in the availability API response. If you want to display fares for customer in any other currency, use currency conversion API.
Pass AgentID (UserID) in the availability request header to get the availability response.
The default values that will be set unless specified:
AvailabilityRequestv2.TaxesAndFees = TaxesAndFeesRollupMode.TaxesAndFees
AvailabilityRequestv2.Criteria.SsrCollectionsMode = AvailabilitySsrCollectionsMode.None
AvailabilityRequestv2.Criteria.Filters.FareInclusionType = AvailabilityType.Default
AvailabilityRequestv2.Criteria.Filters.CompressionType = FareClassControl.LowestFareClass
AvailabilityRequestv2.Criteria.Filters.Loyalty = LoyaltyFilter.MonetaryOnly
AvailabilityRequestv2.Criteria.Filters.FlightType = FlightType.All
AvailabilityRequestv2.Criteria.Filters.ExclusionType = AvailabilityFilter.ExcludeUnavailable
AvailabilityRequestv2.Criteria.Filters.SortOptions = JourneySortKey.LowestFare,JourneySortKey.EarliestDeparture,JourneySortKey.ShortestTravelTime
AvailabilityRequestv2.Filters.ConnectionType = SoldAsConnectionType.None
AvailabilityRequestv2.Criteria.Filters.MaxConnectingFlights = 0
AvailabilityRequestv2.Criteria.Stations.SearchDestinationMacs = false
AvailabilityRequestv2.Criteria.Stations.SearchOriginMacs = false
AvailabilityRequestv2.NumberOfFaresPerJourney = 1
Successful Availability API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Booking Quote (Price Itinerary) - Retrieves fare breakdown, baggage allowance and infant fare based on the request. You will get full value including tax of the each component.
The availability response will only return adult and child fares. When infants are added to a flight search, it is necessary to use the booking quote response to obtain the fares.
Baggage allowance information can also be obtained from the booking quote response.
Pass AgentID in the Booking quote request header to get the response. You can pass one or multiple pairs of journeyKey and fareAvailabilityKey in a single booking quote request. So,
round trips, connecting flights or multiple flights can be queried in a single booking quote API request (Ex. for both inbound and outbound flights). Duplicate journeykey is not allowed in a request. Calling this API is optional and not necessarily happens after each availability request unless the information returned by it is required (infants fare, baggage allowance, fare breakdown …etc.).
Note: Although this endpoint behaves like a GET, POST is used to reduce the limitations resulting from URL length issues. Successful BookingQuote API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Trip Sell - Sells the list of journeys and creates a booking if it doesn't already exist. You can sell the infant using this method. Roundtrips must include journeyKey and fareAvailabilityKey of both outbound and return flights in the same API call.
Pass AgentID in the Trip Sell request header to get the Trip Sell response. Successful TripSell API request and response looks similar to the following:
Add Passenger and Contact Info (Passengers API) – Update the booking passenger(s) information and contact details based on the passenger key.
Use can use the agency contact information to update the contact details.
Pass AgentID in the Add Passenger and contact request header to get the Add Passenger and contact response. Successful Passengers API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Note: Please make sure to pass the correct organization Id to the field “sourceOrganization”
Get Passengers – Get the collection of passenger(s) on the booking along with passengerkey. Successful GetPassengers API request and response looks similar to the following:
7. Seats Availability by segment- checks for available seats for a specific segment of a flight. There need to be a booking in the session (calling TripSell) in order to check seats availability. It takes segmentKey (the journeyKey of the segment you wish to assign seat(s) in it) as a parameter as the following:
Check available seats (if the node value is "5" (Open)). It is important to check the “Availability” node in the seat availability API response before assigning the seat as shown below.
The “availability” key is a single digit and it represents the availability of the seat. It may have the following values [0-'Unknown', 1-'Reserved', 2-'Blocked', 3-'HeldForAnotherSession', 4- 'HeldForThisSession', 5-'Open', 6-'Missing', 7-'CheckedIn', 8-'FleetBlocked', 9-'Restricted', 10- 'Broken', 11-'ReservedForPnr', 12-'SoftBlocked', 13-'Unavailable']. Booking a seat will not succeed if seats availability value is not 5.
For roundtrip flights or connecting flights, checking seat availability and assigning a seat should happen for each segment of the flight.
Obtain the unitKey of the available seat you wish to assign to use it in seatsAssignment API.
8. Seat Assignment- As the name suggests, it assigns a seat for a passenger. The API takes segmentKey (the journeyKey of the journey you wish to assign seat(s) in it) as a parameter. The request body must include the unitkey (obtained by calling get seatsAvailabilityBySegment API) and the passengerkey (obtained by calling GetPassengers API). Successful GetPassengers API request and response looks similar to the following:
9. Get Available SSRs– To get all the available SSRs. Returned SSRs are classified under journey,
segment and leg SSRs. It is important to check this API before adding SSRs since some SSRs may not be available on some airports or even within the same flight (Ex. Due to seat restrictions). Also, you will need to acquire the SSRKey of the SSR (in case it is available) form this API in order to use it in SellSSR API as shown below:
Successful AvailableSSRs API request and response looks similar to the following (refer to test
cases attached to the organization registration email for full APIs examples):
10. Add SSRs (SellSSR) –To add the required SSRs. For connected flights, an SSR need to be available and added to all segments if passenger requested to have SSR on the full flight. For some SSRs (like extra baggage XB10 or XB20), it is a must to have the SSR on both segments. In the request body, use the SSRKey obtained in get AvailableSSRs API. Successful SellSSR API request and response looks similar to the following:
For the Meals SSRs, ssrKey is available under legSsrs tag as below
Check response from /api/jz/v1/Booking/AvailableSSRs,
For the connecting sectors, for meals pass SSR separately for each leg. To get SSRs available for each leg, take response from /api/jz/v1/Booking/AvailableSSRs, check SSRs available for each leg and pass SSRs accordingly,
SSRs like Extra baggage (XB10), PRRT can get from /api/jz/v1/Booking/AvailableSSRs response under journeySsrs for each passenger ssrKey is available.
In case of connection booking, the SSRs like XB10 and PRRT will be added for the whole journey, so it will be applied for both sectors.
In the below figure for XB10, name (highlighted) in the figure below can be taken to display the SSR name for XB10 SSR.
Passenger Availability can check in the /api/jz/v1/Booking/AvailableSSRs response as below. In the figure below we can see the SSR key for TSML (SSR) for the passenger key MCFBRFQ-
For the LOUN corresponding ssrKey is available under segmentSsrs tag in the
/api/jz/v1/Booking/AvailableSSRs response.
11. Commit Booking - Commits stateful changes before making BSP payment. The booking will be
12. Get Booking Status-To get the booking and payments status.
in Hold for 15 minutes until the BSP payment is completed.
Pass BookingDetailsType value as BalanceDue.
The booking will be on “Hold” and the payment status will be “UnderPaid”.
BSP Payment– Add the payment using BSP Payment.
BSP Cash:
TEST URL: https://stg-mapi.jazeeraairways.com/api/jz/ota/bspcash/pay
Headers: Make sure the authorization is provided in the header.
Request Body:
{
}
"serviceType": "Dotrez", "paymentType": "BSPCASH", "accountNumber": ""
Success response: The BSP payment will return success - true in case if the payment is successful and the booking will also be confirmed.
In order to check the booking confirmation please use the Get Booking Status API Request as per point no: 14.
Failure response:
The BSP payment will return success - false in case if the payment is
not successful and the booking will not be confirmed. It will remain on hold for 15 minutes
and then the booking will get hold- Cancelled.
2. BSP Easy Pay:
TEST URL: https://stg-mapi.jazeeraairways.com/api/jz/ota/bspcash/pay
Headers: Make sure the authorization is provided in the header.
Request Body:
{
"serviceType": "Dotrez", "paymentType": "EASYPAY",
"accountNumber": "Ecd4pnJRG27hcVRq/Ku01FNkVJf/9MF85mN0FufGRRp4Gu ouloS0eH//WRprehKOjliz5iqVkWSCGUWIP6SQWeIVD63RHMd0+1N/HZoLOVY0HWYU uJQt02lx//ldo6vOQINe7wdPEcN9qgwpDlFcHVBV2kVVWpo0lEhnvZmV5Wts3Vm5Pn saT3t6m3HKE/aChFDNV+4vYUAiOBqXBPR42fKmlbFQ9NyXPU4FoCfyoKY9sEL1m4n2 7+RZwgQL8ttgGdr7HyPQkgA2AFa5au+/B+0+Fk1wik5aBhPscPh/08xjabY7myoH1L 6ldIZ8MNc/+VFdTw=="
}
Note:
The above highlighted part accountNumber is an encrypted string consisting of account Number and expiry date.
Kindly construct ‘account Number’ and ‘expiry date’ in the JSON format as –
{
"accountNumber":"169898803734295", "expiryDate"":"0223"
}
and encrypt using RSA algorithm with the public key. The public key will be shared in separate mail on request.
Success response: The BSP payment will return success - true in case if the payment is successful and the booking will also be confirmed.
In order to check the booking confirmation please use the Get Booking Status API Request as per point no: 14.
Failure response: The BSP payment will return success - false in case if the payment is not successful and the booking will not be confirmed. It will remain on hold for 15 minutes and then the booking will get hold- Cancelled.
Get Booking Status-To get the booking and payments status.
Pass BookingDetailsType value as BalanceDue.
For confirmed bookings and in BookingDetails API response:
status should be “Confirmed”.
paidStatus should be ”PaidInFull”.
balanceDue should be zero as shown below:
For unsuccessful (Failed) payments, the BookingDetails API response is as below:
status will be “Hold”.
paidStatus will be ”UnderPaid”.
balanceDue will be same booking amount.
Logout- Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it). API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Booking Flow (For Credit Card (CC) Payment)
The following information describes the steps used to make a booking using CC Payment. Refer to section 5.1 (New Booking) to check the basic and mandatory steps to make a booking using CC Payment. Remaining APIs are optional and can be used if needed. Also, for each API, check its corresponding test case (in the test cases file attached to OTA registration email) in-order-to see its request body and the corresponding successful response.
Get Token – Creates the general access token that will grant access to the API. Token idle time out is 15 minutes. That is, the token will expire if idle time between each two consecutive API calls is greater than or equal to 15 minutes.
Token API should be used wisely as each successful login is associated with one session. Please refer to section 2.1 for best practices regarding session management and avoiding resource leaking.
Successful Token API request and response looks similar to the following (refer to test cases attached in the organization registration email for full examples including request body and header data (using Postman or Swagger). Agents may require whitelisting server IP address.
Get Availability – Searches for flights with the full availability search request. This request allows for total control over the configuration or criteria. If a property is not set, default values will be set instead. These defaults are what we consider a general optimized request. If these optimizations are not preferred the requester will need to opt out the filters on the availability request.
Note: You'll always receive the fares in availability response in origin station default currency regardless of which currency you pass in the request. All the remaining API call requests (BookingQuote, TripSell, BookingCommit, etc) need to use the currency specified in the availability API response. If you want to display fares for customer in any other currency, use currency conversion API.
AvailabilityRequestv2.TaxesAndFees = TaxesAndFeesRollupMode.TaxesAndFees
AvailabilityRequestv2.Criteria.SsrCollectionsMode = AvailabilitySsrCollectionsMode.None
AvailabilityRequestv2.Criteria.Filters.FareInclusionType = AvailabilityType.Default
AvailabilityRequestv2.Criteria.Filters.CompressionType = FareClassControl.LowestFareClass
AvailabilityRequestv2.Criteria.Filters.Loyalty = LoyaltyFilter.MonetaryOnly
AvailabilityRequestv2.Criteria.Filters.FlightType = FlightType.All
AvailabilityRequestv2.Criteria.Filters.ExclusionType = AvailabilityFilter.ExcludeUnavailable
AvailabilityRequestv2.Criteria.Filters.SortOptions = JourneySortKey.LowestFare,JourneySortKey.EarliestDeparture,JourneySortKey.ShortestTravelTime
AvailabilityRequestv2.Filters.ConnectionType = SoldAsConnectionType.None
AvailabilityRequestv2.Criteria.Filters.MaxConnectingFlights = 0
AvailabilityRequestv2.Criteria.Stations.SearchDestinationMacs = false
AvailabilityRequestv2.Criteria.Stations.SearchOriginMacs = false
AvailabilityRequestv2.NumberOfFaresPerJourney = 1
Successful Availability API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Pass AgentID (UserID) in the availability request header to get the availability response. The default values that will be set unless specified:
Booking Quote (Price Itinerary) - Retrieves fare breakdown, baggage allowance and infant fare based on the request. You will get full value including tax of the each component.
The availability response will only return adult and child fares. When infants are added to a flight search, it is necessary to use the booking quote response to obtain the fares.
Baggage allowance information can also be obtained from the booking quote response.
Pass AgentID in the Booking quote request header to get the response. You can pass one or multiple pairs of journeyKey and fareAvailabilityKey in a single booking quote request. So, round trips, connecting flights or multiple flights can be queried in a single booking quote API request (Ex. for both inbound and outbound flights). Duplicate journeykey is not allowed in a request. Calling this API is optional and not necessarily happens after each availability request unless the information returned by it is required (infants fare, baggage allowance, fare breakdown …etc.).
Note: Although this endpoint behaves like a GET, POST is used to reduce the limitations resulting from URL length issues. Successful BookingQuote API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Trip Sell - Sells the list of journeys and creates a booking if it doesn't already exist. You can sell the infant using this method. Roundtrips must include journeyKey and fareAvailabilityKey of both outbound and return flights in the same API call.
Pass AgentID in the Trip Sell request header to get the Trip Sell response. Successful TripSell API request and response looks similar to the following:
Add Passenger and Contact Info (Passengers API) – Update the booking passenger(s) information and contact details based on the passenger key.
Use can use the agency contact information to update the contact details.
Pass AgentID in the Add Passenger and contact request header to get the Add Passenger and contact response. Successful Passengers API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Note: Please make sure to pass the correct organization Id to the field “sourceOrganization”
Get Passengers – Get the collection of passenger(s) on the booking along with passengerkey. Successful GetPassengers API request and response looks similar to the following:
Seats Availability by segment- checks for available seats for a specific segment of a flight. There need to be a booking in the session (calling TripSell) in order to check seats availability. It takes segmentKey (the journeyKey of the segment you wish to assign seat(s) in it) as a parameter as the following:
Check available seats (if the node value is "5" (Open)). It is important to check the “Availability” node in the seat availability API response before assigning the seat as shown below.
The “availability” key is a single digit and it represents the availability of the seat. It may have the following values [0-'Unknown', 1-'Reserved', 2-'Blocked', 3-'HeldForAnotherSession', 4- 'HeldForThisSession', 5-'Open', 6-'Missing', 7-'CheckedIn', 8-'FleetBlocked', 9-'Restricted', 10- 'Broken', 11-'ReservedForPnr', 12-'SoftBlocked', 13-'Unavailable']. Booking a seat will not succeed if seats availability value is not 5.
For roundtrip flights or connecting flights, checking seat availability and assigning a seat should happen for each segment of the flight.
Obtain the unitKey of the available seat you wish to assign to use it in seatsAssignment API.
Seat Assignment- As the name suggests, it assigns a seat for a passenger. The API takes segmentKey (the journeyKey of the journey you wish to assign seat(s) in it) as a parameter. The request body must include the unitkey (obtained by calling get seatsAvailabilityBySegment API) and the passengerkey (obtained by calling GetPassengers API). Successful GetPassengers API request and response looks similar to the following:
9. Get Available SSRs– To get all the available SSRs. Returned SSRs are classified under
journey, segment and leg SSRs. It is important to check this API before adding SSRs since some SSRs may not be available on some airports or even within the same flight (Ex. Due to seat restrictions). Also, you will need to acquire the SSRKey of the SSR (in case it is available) form this API in order to use it in SellSSR API as shown below:
Successful AvailableSSRs API request and response looks similar to the following (refer to test
cases attached to the organization registration email for full APIs examples):
10. Add SSRs (SellSSR) –To add the required SSRs. For connected flights, an SSR need to be available and added to all segments if passenger requested to have SSR on the full flight. For some SSRs (like extra baggage XB10 or XB20), it is a must to have the SSR on both segments. In the request body, use the SSRKey obtained in get AvailableSSRs API. Successful SellSSR API request and response looks similar to the following:
For the Meals SSRs, ssrKey is available under legSsrs tag as below
Check response from /api/jz/v1/Booking/AvailableSSRs,
For the connecting sectors, for meals pass SSR separately for each leg. To get SSRs available for each leg, take response from /api/jz/v1/Booking/AvailableSSRs, check SSRs available for each leg and pass SSRs accordingly,
SSRs like Extra baggage (XB10), PRRT can get from /api/jz/v1/Booking/AvailableSSRs response Under journeySsrs for each passenger ssrKey is available.
In case of connection booking, the SSRs like XB10 and PRRT will be added for the whole journey, so it will be applied for both sectors.
In the below figure for XB10, name (highlighted) in the figure below can be taken to display the SSR name for XB10 SSR.
Passenger Availability can check in the /api/jz/v1/Booking/AvailableSSRs response as below. In the figure below we can see the SSR key for TSML (SSR) for the passenger key MCFBRFQ-
For the LOUN corresponding ssrKey is available under segmentSsrs tag in the
/api/jz/v1/Booking/AvailableSSRs response.
11. Commit Booking - Commits stateful changes before making BSP payment. The booking
12. Get Booking Status-To get the booking and payments status.
will be in Hold for 15 minutes until the BSP payment is completed.
Pass BookingDetailsType value as BalanceDue.
The booking will be on “Hold” and the payment status will be “UnderPaid”.
13. CC Payment– Add the payment using CC Payment.
GET TEST URL:
Query Parameters:
returnUrl="website return url after payment",
paymentMethod="CreditCard/CreditCard_Amex/Payu"
Headers: Make sure the authorization is provided in the header.
Success Response:
Steps for CC (Credit Card) payment success or failure check:
The CC payment will return a URL which has to be used for making the payments.
Once the payment is competed the page navigates to the returnURL page which was provided as query param.
Below sample return URL:
https://test.com/TestForCC?order_no=W4KPYV63812345116584483&session_id=473c3 63d485bea9eb246a74ea7104a6242a7d440&reference_number=R7353&expiry_date=& data=eyJ0b2tlbiI6ImV5SmhiR2NpT2lKSVV6STFWNDSTZJa3BYVkNKOS5leUp6ZFdJaU9pSlB WRUVpTENKcWRHa2lPURZNFppMWhZMkpqTmpRM04yWTJPVGNpTENKcGMzTWlPaUp rYjNSU1JWb2dHVSNWo0bm1XQnU5TGYzbnM4Q3pfNFBzX2RjRGxHU002bHQ2UEEiLCJib
29raW5nQW1vdW50IjoiNzIuOTYiLCJib29raW5nQ3VycmVuY3kiOiJLV0QiLCJyZWNvcmRM b2NhdG9yIjoiVzRLUFlWIiwicGxhdEZvcm0iOiJXZWIiLCJvcmRlcm5vIjpudWxsfQ%3D%3D& user_defined_field=PNR-W4KPYV
A check has to be made in the return URL page if the payment was successful or not as in both the cases same return URL will be retrieved.
In order to get the booking and payments status within the returnURL page, call the get booking status endpoint.
Get Booking Status-To get the booking and payments status.
Pass BookingDetailsType value as BalanceDue.
For successful payment:
For confirmed bookings and in BookingDetails API response:
Status should be “Confirmed”.
paidStatus should be ”PaidInFull”.
balanceDue should be zero as shown below:
For unsuccessful (Failed) payments:
The BookingDetails API response is as below:
Status will be “Hold”.
paidStatus will be ”UnderPaid”.
balanceDue will be same booking amount.
In case of failure you call the CC payment URL again and enter the valid details for successful booking. If the payment is not successful with in 15min the booking would be cancelled.
Logout- Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it). API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Hold Booking Flow (Only for AG Payment)
The following information describes the steps used to make a hold booking using AG Payment. Refer to section 5.2 (Hold Booking) to check the basic and mandatory steps to make a hold booking using AG Payment. Remaining APIs are optional and can be used if needed. Also, for each API, check its corresponding test case (in the test cases file attached to OTA registration email) in- order-to see its request body and the corresponding successful response.
Kindly please refer to section 5.9.2 Booking flow (For AG account) points 1-6.
7 Get Available Hold date – retrieves the recommended hold date if hold is available. Successful
request and response looks similar to the below:
Note: Kindly please note that this hold date should always be greater than 20hrs only then
the hold functionality will be processed.
Since the hold functionality will not be available for few configurable changes (ex: early departure date, certain fares etc.) so kindly please make a check for the Available Hold Date.
8 Add Fee: As the name suggests, it adds hold fee for passengers based on the passenger key. The request body must include the passenger key (obtained by calling GetPassengers API), fee code (HTA), origin of the booking and currency code (Availability response currency code. Successful Add Fee API request and response looks similar to the following:
Note: The Hold service fee (HTA) should be added to all the passengers on the booking.
One way:
On the journey for all the passengers.
Ex: KWI-DXB (2 passengers), the HTA fee should be added for all the passengers for KWI- DXB (so all together 2 HTA for 2 passengers with the origin as KWI (origin of the journey)).
Return:
On the first journey for all the passengers.
Ex: KWI-DXB (2 passengers), the HTA fee should be added for all the passengers for KWI- DXB (So all together 2 HTA for 2 passengers with the origin as KWI (origin of the journey)).
Connecting one way:
On the journey for all the passengers.
Ex: KTM-DXB (2 passengers), the HTA fee should be added for all the passengers for KTM- KWI (So all together 2 HTA for 2 passengers with the origin as KTM (origin of the journey)).
Connecting Return:
On the first journey for all the passengers.
Ex: KTM-DXB (2 passengers), the HTA fee should be added for all the passengers for KTM- KWI (So all together 2 HTA for 2 passengers with the origin as KTM (origin of the journey)).
Add payment to booking – Update the payment using Agency account (AG) mode. Account number (ACCTNO) should be the Organization ID.
Include the parameter deposit as true.
Pass the sum of the amount (Hold booking Service Fee) retrieved from get passengers API fees codes as “HTA” for all passengers which was added in the above step.
Sample Response of get passengers API after adding HTA fee for two passengers
Consider the sum of above highlighted amount for all the passengers and pass this to the amount of Add payment request along with deposit flag true as below:
Request for Add payment to booking:
Response is similar to that of normal booking.
Commit booking – Commits state full changes made and finalize the booking. The amount paid should match to the sum of the amount retrieved from get passengers API fees codes as “HTA” for all passengers.
Hold booking: Always pass the expiration date retrieved from getavailableholddate API.
Also add new header parameter confirmHoldBooking and pass it as true for only hold bookings and rest all do not pass any value.
Logout- Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it). API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Steps to complete and confirm the Hold Booking with in the allotted time:
Login – Generate token as that of normal booking flow.
Retrieve the PNR/Record Locator – Gets a specific booking by record locator and stores it in the state. The API takes Record Locator (PNR) as a parameter. The Successful RetrieveBookingByRecordLocator API response looks similar to the following:
3 Check the balance due - Get Booking Status-To get the balance due
Pass BookingDetailsType value as BalanceDue.
4 Add Payment to booking - Update the payment using Agency account (AG) mode. Account number (ACCTNO) should be the Organization ID.
Adding any paid services need to have corresponding payment added. To pay in full, take amount (balance due) from booking details API and pass it in the Add Payment request.
In Swagger,
Pass AgentID in the Add Payment request header and pass your organization ID as a value for ACCTNO. Over or underpayment is not allowed and committing the booking will not succeed is such case. Successful AddPaymentToBooking APIrequest and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
5 Commit Booking - Commits stateful changes made and finalize the booking. In case of
overpayments or underpayments, commit booking API will not succeed. The amount paid
Confirmed booking: Always check the “balanceDue” parameter in the commit booking response to make sure the booking is confirmed or not. It will be zero for confirmed bookings.
Itinerary sending option can be controlled from booking commit request by setting
“notifyContacts”- true/false.
should match to the due
Itinerary sending option is disabled in production and the itinerary emails will be triggered only from TEST environment.
This feature will be enabled the production environment, upon request from the agency. Pass AgentID in the commit booking request header. Successful AddPaymentToBooking API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples). The PNR (recordLocator) will be included the response of this API)
Get Booking Status-To get the booking and payments status.
Pass BookingDetailsType value as BalanceDue.
For confirmed bookings and in BookingDetails API response:
status should be “Confirmed”.
paidStatus should be ”PaidInFull”.
balanceDue should be zero as shown below:
Logout- Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it). API request and
response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
API URL: https://rtestupgrade.jazeeraairways.com/swagger/
Swagger: https://rtestupgrade.jazeeraairways.com/swagger/
Logon information (Token)
The Logon API is used to generate token. It is required the username (agent ID or User ID) and the password to generate the token.
POST https://rtestupgrade.jazeeraairways.com/api/jz/v1/Token
Request:
{
"credentials": {
"userName": "************", "password": "***********", "domain": "WW2", "channelType": "API"
},
"applicationName": "OTA"
}
Response:
{
"data": {
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJPVEEiLCJqdGkiOiI1YjJ hYzc4Ni0yZmQ5LTZkNWItY2I1Yi1hZTc1YTVkNjQ1ZjEiLCJpc3MiOiJkb3RSRVogQVBJIn0.j1LL14YrZHJfu htzj9FNlkTIFPtVu5gBXpI0lk_KapQ",
"idleTimeoutInMinutes": 15
}
}
Here the token received from Logon response is required to be passed as the header parameter (Authorization) in all other requests.
Logout
Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it).
DELETE https://rtestupgrade.jazeeraairways.com/api/jz/v1/Token
Modify Booking Flow:
The API call sequence for modify booking is as follows.
Acquire a token (login)
Retrieve the booking using PNR/Record locator
Rebook search with current booking defaults
Booking Quote for new search
Delete Journey based on journey key
Resell journeys
Resell SSR if exists
Get Seat Availability
Seat Assignment if exists (from the same seat group of the modifying journey(old))
Get Booking Details for Balance Due
Check Agency account balance
Add Payment to booking
Commit booking
Get booking Details
Logout
Cancel Booking Flow:
The API call sequence for cancel booking is as follows.
Acquire a token (login)
Retrieve the booking using PNR/Record locator
Delete Journey based on journey key
Get Booking Details for Balance Due
Add CS refund to booking (Only AG Mode)
Commit booking
Get booking Details
Logout
MODIFY BOOKING FLOW:
Retrieve the booking using PNR/Record locator:
Gets a specific booking by record locator and stores it in the state. The API takes Record Locator (PNR) as a parameter. The Successful RetrieveBookingByRecordLocator API response looks similar to the following:
In order to modify a journey, we must first delete the current journey and then add the new journey. Identify the journey to be modified and get the journey key.
Rebook search with current booking defaults:
Retrieves the flight availability for the new search with the current booking defaults (Only the date can be modified).
Only date for the booking can be modified and rest search requests should be same as original booking.
In case of round trip booking, it is necessary to pass both the inbound & outbound search requests, even if we are changing only one flight.
Make sure to set the minimum price (minPrice) amount, which is obtained from the corresponding journey segment.
Original fare amount can be retrieved from Retrieve the booking using PNR/Record locator response – journeys/segment/fares/passengerFares/ (service charges-Type : 0).
Set the original fare amount as minPrice in the request for rebook availability.
Pass AgentID (UserID) in all the request headers to get the responses.
Booking quote for new search:
Retrieves fare breakdown, baggage allowance and infant fare based on the request. You will get full value including tax of the each component.
Similar to Normal Booking Quote request.
Pass AgentID (UserID) in all the request headers to get the responses.
Delete Journey based on journey key:
Add new header parameter CancelModifyFlag and pass it as modify for modifying the booking.
Also pass AgentID (UserID) in all the request headers to get the responses.
Resell journeys:
Sells the list of journeys and creates a booking if it doesn't already exist.
Pass AgentID (UserID) in all the request headers to get the responses.
Each adult passenger is associated with "passengerTypeCode": "ADT" Each Child Passenger is associated with "passengerTypeCode": "CHD"
Journey Key, Fare Availability Key, and currency code to be considered from Rebook Availability Response.
This is for 1 adult, 1 child.
{
"keys": [
{
"journeyKey": "Sjl_IDQwM34gfn5LV0l_MDEvMTEvMjAyNCAxODoyNX5IWUR_MDEvMTIvMjAyNCAwMTozNX5_",
"fareAvailabilityKey": "MH5LfiB_Sjl_S0xTUE9XS1d_WEUzMH5_MH45fn5YITA-", "standbyPriorityCode": "",
"inventoryControl": ""
}
],
"passengers": { "types": [
{
"count": 1
"type": "ADT",
},
{
}
],
"residentCountry": "KW"
},
"currencyCode": "KWD", "infantCount": 0, "promotionCode": "",
"sourceOrganization": ""
}
"count": 1
"type": "CHD",
Resell SSR:
Endpoint: /api/jz/v1/ManageBooking/ResellSSR
Resell the SSRs if any SSRs (meals, extra baggage etc) were included in the booking.
Each infant is associated with adult passenger is from GetBookingBy PNR & Last name response mapping data.passengers.{passengerKey}.infant if this is null then infants are not present and if data is present then infants are present on booking. (Please consider the sum for all adult passengers here).
Each SSR is obtained from from GetBookingBy PNR & Last name response mapping data.journeys.segments.passengerSegment.{PassengerKey}.ssrs even if one passenger has SSRS added on the booking Resell SSRs API should be called.
Pass AgentID (UserID) in all the request headers to get the responses.
Seats Availability by segment- Endpoint:
/api/jz/v1/SeatsAvailabilityBySegment?segmentkey=Sjl_MDUvMjAyNCAxMDowNX5_
Checks for available seats for a specific segment of a flight. There need to be a booking in the session (calling Re Sell Trip) in order to check seats availability. It takes segmentKey (the journeyKey of the segment you wish to assign seat(s) in it) as a parameter as the following:
Check available seats (if the node value is "5" (Open)). It is important to check the “Availability” node in the seat availability API response before assigning the seat as shown below.
The “availability” key is a single digit and it represents the availability of the seat. It may have the following values [0-'Unknown', 1-'Reserved', 2-'Blocked', 3-'HeldForAnotherSession', 4- 'HeldForThisSession', 5-'Open', 6-'Missing', 7-'CheckedIn', 8-'FleetBlocked', 9-'Restricted', 10- 'Broken', 11-'ReservedForPnr', 12-'SoftBlocked', 13-'Unavailable']. Booking a seat will not succeed if seats availability value is not 5.
For roundtrip flights or connecting flights, checking seat availability and assigning a seat should happen for each segment of the flight.
Obtain the unitKey of the available seat you wish to assign to use it in seatsAssignment API.
Seat Assignment:
Endpoint: /api/jz/v1/seatsAssignment?segmentkey={segmentkey}
In case if seats were assigned for the earlier booking make sure you assign seats for the same seat group.
Note: In order to identify the seat group please consider the GetbookingBy PNR & lastname response mapping data.journeys.segments.passengerSegment.{PassengerKey}.seats[i]. seatInformation.seatSet
Compare the seats availability by segment response for the modified segment with the above seat sets. In case if same seat group or the lowest seat group is available assignment of seat will be free of charge.
Get Booking Details for Balance Due:
Endpoint: /api/jz/v1/BookingDetails (Pass BookingDetailsType value as BalanceDue).
/api/jz/v1/BookingDetails?BookingDetailsType= BalanceDue
Check the balance due - Get Booking Status-To get the balance due.
Check Agency account balance:
To make sure the agency account has sufficient account balance to make the payment/booking. The response will contain the below:
Add payment to booking:
Update the payment using Agency account (AG) mode. Account number (ACCTNO) should be the Organization ID.
To pay in full, take amount (balance due) from Get Booking Details for Balance Due and pass it in the Add Payment request
Pass AgentID (UserID) in all the request headers to get the responses.
Commit Booking:
Commits stateful changes made and finalize the booking. The amount paid should match to the due Confirmed booking: Always check the “balanceDue” parameter in the commit booking response to make sure the booking is confirmed or not. It will be zero for confirmed bookings.
Itinerary sending option can be controlled from booking commit request by setting
Pass AgentID (UserID) in all the request headers to get the responses.
Get booking From Session:
/api/jz/v1/BookingDetails?BookingDetailsType=Complete
To get all the details of the booking.
Cancel Booking Flow:
Gets a specific booking by record locator and stores it in the state. The API takes Record Locator (PNR) as a parameter. The Successful RetrieveBookingByRecordLocator API response looks similar to the following:
In order to cancel a journey, we must first delete the current journey.
Partial cancellation not allowed for the roundtrip booking. In case of roundtrips both the journeys have to be deleted.
Delete Journey based on journey key:
Deletes the Journey based on journey key obtained from above step.
Add new header parameter CancelModifyFlag and pass it as cancel for cancelling the booking.
Also pass AgentID (UserID) in all the request headers to get the responses.
Get booking From Session:
/api/jz/v1/BookingDetails?BookingDetailsType=Complete
The booking must be obtained from the booking in state to receive the outstanding amount after cancellation.
Add CS payment to booking:
For credit shell, take amount (balance due) from Get Booking Details for Balance Due and pass it in the Add Payment request along with the payment key.
Pass AgentID (UserID) in all the request headers to get the responses.
Commit Booking:
Commits stateful changes made and finalize the booking. The amount paid should match to the due
Confirmed booking: Always check the “balanceDue” parameter in the commit booking response to make sure the booking is confirmed or not. It will be zero for confirmed bookings.
Airline itinerary sending option can be controlled from booking commit request by setting
Pass AgentID (UserID) in all the request headers to get the responses.
Service Bundles (Ancillary) Flow:
The API call sequence for adding an ancillary on a booking is as follows.
Acquire a token (login)
Get Availability
Sell Flights
Get passenger
Add Passenger
Call Bundle Availability
Get details for Bundles such as name to display
Add Bundle to booking
Get Seat Availability
Seat Assignment if exists within the bundle option (for available groups)
Get Booking Details for Balance Due
Check Agency account balance
Add Payment to booking
Commit booking
Get booking Details
Logout
Get Token – Creates the general access token that will grant access to the API. Token idle time out is 15 minutes. That is, the token will expire if idle time between each two consecutive API calls is greater than or equal to 15 minutes.
Token API should be used wisely as each successful login is associated with one session. Please refer to section 2.1 for best practices regarding session management and avoiding resource leaking.
Successful Token API request and response looks similar to the following (refer to test cases attached in the organization registration email for full examples including request body and header data (using Postman or Swagger). Agents may require whitelisting server IP address.
2. Get Availability – Searches for flights with the full availability search request. This request allows for total control over the configuration or criteria. If a property is not set, default values will be set instead. These defaults are what we consider a general optimized request. If these optimizations are not preferred the requester will need to opt out the filters on the availability request.
Note: You'll always receive the fares in availability response in origin station default currency regardless of which currency you pass in the request. All the remaining API call requests (BookingQuote, TripSell, BookingCommit, etc) need to use the currency specified in the availability API response. If you want to display fares for customer in any other currency, use currency conversion API.
Pass AgentID (UserID) in the availability request header to get the availability response. The default values that will be set unless specified:
TaxesAndFees = TaxesAndFeesRollupMode.None
Criteria.SsrCollectionsMode = AvailabilitySsrCollectionsMode.None
Criteria.Filters.FareInclusionType = AvailabilityType.Default
Criteria.Filters.CompressionType = FareClassControl.LowestFareClass
Criteria.Filters.Loyalty = LoyaltyFilter.MonetaryOnly
Criteria.Filters.FlightType = FlightType.All
Criteria.Filters.ExclusionType = AvailabilityFilter.ExcludeUnavailable
Criteria.Filters.SortOptions =
JourneySortKey.LowestFare, JourneySortKey.EarliestDeparture, JourneySortKey.ShortestTravelTime
Filters.ConnectionType = SoldAsConnectionType.None
Criteria.Filters.MaxConnectingFlights = 0
Criteria.Stations.SearchDestinationMacs = false
Criteria.Stations.SearchOriginMacs = false
Criteria.Filters.BundleControlFilter = BundleControlFilter.Disabled
NumberOfFaresPerJourney = 1
Successful Availability API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Booking Quote (Price Itinerary) - Retrieves fare breakdown, baggage allowance and infant
fare based on the request. You will get full value including tax of the each component.
The availability response will only return adult and child fares. When infants are added to a flight search, it is necessary to use the booking quote response to obtain the fares.
Baggage allowance information can also be obtained from the booking quote response.
Pass AgentID in the Booking quote request header to get the response. You can pass one or multiple pairs of journeyKey and fareAvailabilityKey in a single booking quote request. So, round trips, connecting flights or multiple flights can be queried in a single booking quote API request (Ex. for both inbound and outbound flights). Duplicate journeykey is not allowed in a request. Calling this API is optional and not necessarily happens after each availability request unless the information returned by it is required (infants fare, baggage allowance, fare breakdown …etc.).
Note: Although this endpoint behaves like a GET, POST is used to reduce the limitations resulting from URL length issues. Successful BookingQuote API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Trip Sell - Sells the list of journeys and creates a booking if it doesn't already exist. You can sell the infant using this method. Roundtrips must include journeyKey and fareAvailabilityKey of both outbound and return flights in the same API call.
Pass AgentID in the Trip Sell request header to get the Trip Sell response. Successful TripSell API request and response looks similar to the following:
Get Passengers – Get the collection of passenger(s) on the booking along with passengerkey. Successful GetPassengers API request and response looks similar to the following:
Add Passenger and Contact Info (Passengers API) – Update the booking passenger(s) information and contact details based on the passenger key.
Use can use the agency contact information to update the contact details.
Pass AgentID in the Add Passenger and contact request header to get the Add Passenger and contact response. Successful Passengers API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
7. Call Bundle Availability - Retrieves the bundle and ssr availability for the booking in-state.
8. Get Bundles Details based on Bundle Code – Retrives the specific bundles configuration based on the bundle code.
Sell Bundles for the Journey –
Based on the choice for selling the service bundle we can pass only the journey key and bundle code to be applied for all the passengers on the journey.
Else if we need to pass it for specific passengers we can pass the passenger Keys along with the bundle code.
bundleCode (string): The bundle code to sell.
passengerKeys (Array[string], optional): A list of passengers to sell the bundle for.
Seats Availability by segment- checks for available seats for a specific segment of a flight. There need to be a booking in the session (calling TripSell) in order to check seats availability. It takes segmentKey (the journeyKey of the segment you wish to assign seat(s) in it) as a parameter as the following:
Check available seats (if the node value is "5" (Open)). It is important to check the “Availability” node in the seat availability API response before assigning the seat as shown below.
The “availability” key is a single digit and it represents the availability of the seat. It may have the following values [0-'Unknown', 1-'Reserved', 2-'Blocked', 3-'HeldForAnotherSession', 4- 'HeldForThisSession', 5-'Open', 6-'Missing', 7-'CheckedIn', 8-'FleetBlocked', 9-'Restricted', 10- 'Broken', 11-'ReservedForPnr', 12-'SoftBlocked', 13-'Unavailable']. Booking a seat will not succeed if seats availability value is not 5.
For roundtrip flights or connecting flights, checking seat availability and assigning a seat should happen for each segment of the flight.
Obtain the unitKey of the available seat you wish to assign to use it in seatsAssignment API.
11. Seat Assignment- As the name suggests, it assigns a seat for a passenger. The API takes
segmentKey (the journeyKey of the journey you wish to assign seat(s) in it) as a parameter. The request body must include the unitkey (obtained by calling get seatsAvailabilityBySegment API) and the passengerkey (obtained by calling GetPassengers API). Successful GetPassengers API request and response looks similar to the following:
12 Check the balance due - Get Booking Status-To get the balance due
Pass BookingDetailsType value as BalanceDue.
13 Add Payment to booking - Update the payment using Agency account (AG) mode. Account number (ACCTNO) should be the Organization ID.
Adding any paid services need to have corresponding payment added. To pay in full, take amount (balance due) from booking details API and pass it in the Add Payment request.
In Swagger,
Pass AgentID in the Add Payment request header and pass your organization ID as a value for ACCTNO. Over or underpayment is not allowed and committing the booking will not succeed is such case. Successful AddPaymentToBooking APIrequest and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
14 Commit Booking - Commits stateful changes made and finalize the booking. In case of
overpayments or underpayments, commit booking API will not succeed. The amount paid
Confirmed booking: Always check the “balanceDue” parameter in the commit booking response to make sure the booking is confirmed or not. It will be zero for confirmed bookings.
Itinerary sending option can be controlled from booking commit request by setting
“notifyContacts”- true/false.
should match to the due
Itinerary sending option is disabled in production and the itinerary emails will be triggered only from TEST environment.
This feature will be enabled the production environment, upon request from the agency. Pass AgentID in the commit booking request header. Successful AddPaymentToBooking API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples). The PNR (recordLocator) will be included the response of this API)
Get Booking Status-To get the booking and payments status.
Pass BookingDetailsType value as BalanceDue.
For confirmed bookings and in BookingDetails API response:
status should be “Confirmed”.
paidStatus should be ”PaidInFull”.
balanceDue should be zero as shown below:
Logout- Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it). API request and
response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):
Jazeera Airways, Kuwait
Website: https://www.jazeeraairways.com/